2 KV 캐시(Key-Value Cache) 증가와 메모리 대역폭 한계

트랜스포머(Transformer) 아키텍처가 자연어 처리(NLP) 생태계를 장악한 이래, 모델의 파라미터 수는 기하급수적으로 증가해 왔다. 그러나 거대 언어 모델(Large Language Model, LLM)을 실제 서비스 환경에 배포하고 운영하는 단계에서 마주하는 가장 치명적인 병목은 의외로 연산 능력(Compute) 그 자체가 아닌, 바로 ‘메모리(Memory)’ 시스템에 있다. 특히 모델이 생성해야 할 시퀀스의 길이(Context Length)가 길어질수록, 추론 과정에서 필연적으로 발생하는 ’KV 캐시(Key-Value Cache)’의 증가는 물리적인 GPU 메모리 용량을 잠식할 뿐만 아니라, 메모리 대역폭(Memory Bandwidth)의 한계를 드러내며 추론 속도와 처리량(Throughput)을 급격히 저하시키는 원인이 된다. 본 장에서는 트랜스포머 아키텍처의 자회귀적(Autoregressive) 추론 과정에서 발생하는 KV 캐시의 생성 원리와 그에 따른 시스템적 부하를 심층적으로 분석하고, 이것이 왜 하드웨어의 발전만으로는 해결될 수 없는 구조적 난제인지, 그리고 맘바(Mamba)와 같은 새로운 아키텍처가 왜 필연적인 대안으로 부상하게 되었는지를 논증한다.

1. 자회귀 추론과 KV 캐시의 구조적 필연성

트랜스포머 모델의 텍스트 생성은 본질적으로 자회귀적이다. 즉, 시점 t에서의 출력 토큰 x_t는 이전 시점까지의 모든 입력 x_{1:t-1}을 조건부로 하여 확률적으로 결정된다. 이러한 순차적 생성 과정에서 핵심적인 역할을 하는 것이 바로 ‘어텐션(Attention)’ 메커니즘이다. 어텐션은 현재 생성하려는 토큰(Query)과 과거의 모든 토큰(Key, Value) 간의 상호작용을 계산하여 문맥 정보를 추출한다.

1.1 어텐션 연산의 중복성과 캐싱의 필요성

표준적인 스케일드 닷 프로덕트 어텐션(Scaled Dot-Product Attention)은 다음과 같이 정의된다:
\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V
여기서 Q(Query), K(Key), V(Value)는 입력 시퀀스의 각 토큰이 가중치 행렬 W_Q, W_K, W_V에 의해 투영(Projection)된 벡터들이다. 자회귀 추론 시, 모델은 t번째 토큰을 생성하기 위해 t번째 위치의 쿼리 벡터 q_t를 계산하고, 이를 1부터 t까지의 모든 키 벡터 k_{1:t}와 내적(Dot Product)하여 어텐션 스코어를 구한 뒤, 값 벡터 v_{1:t}와 가중합을 수행한다.1

만약 매 생성 단계마다 과거의 모든 토큰(x_1,..., x_{t-1})에 대해 K와 V 벡터를 다시 계산한다면, 시퀀스 길이가 L일 때 전체 연산량은 O(L^3) 혹은 그 이상으로 급증하게 되며, 이는 실시간 추론을 불가능하게 만든다. 이러한 비효율을 방지하기 위해, 한 번 계산된 과거 토큰들의 K와 V 벡터를 GPU 메모리(VRAM)에 저장해두고 재사용하는 기법이 바로 **KV 캐시(KV Cache)**이다.3

KV 캐시를 사용하면, t 시점에서는 오직 현재 토큰 x_t에 대한 k_t, v_t만 계산하여 기존 캐시에 추가(Append)하고, 저장된 K, V 행렬을 불러와 어텐션 연산만 수행하면 된다. 이를 통해 연산 복잡도를 획기적으로 줄일 수 있다. 그러나 이 방식은 ’연산(Compute)’을 아끼는 대신 ’메모리(Memory)’를 희생하는 트레이드오프(Trade-off) 전략이며, 바로 이 지점에서 현대 LLM의 근본적인 병목이 시작된다.4

1.2 KV 캐시 용량의 정량적 분석

KV 캐시가 점유하는 메모리 공간은 모델의 크기와 시퀀스 길이에 선형적으로 비례하여 증가한다. 이를 정량적으로 분석하기 위해 다음과 같은 변수들을 정의한다:

• B: 배치 크기 (Batch Size)
• L: 시퀀스 길이 (Sequence Length, 프롬프트 + 생성된 토큰)
• n_{\text{layers}}: 트랜스포머 레이어 수
• n_{\text{heads}}: 어텐션 헤드 수
• d_{\text{head}}: 헤드 차원 (일반적으로 d_{\text{model}} / n_{\text{heads}})
• P_{\text{prec}}: 파라미터 정밀도 (Bytes, e.g., FP16=2, FP32=4)

이때, 전체 KV 캐시의 크기(M_{\text{KV}})는 다음과 같은 수식으로 도출된다4:
M_{\text{KV}} = 2 \times B \times L \times n_{\text{layers}} \times n_{\text{heads}} \times d_{\text{head}} \times P_{\text{prec}}
여기서 계수 ’2’는 Key와 Value 두 개의 행렬을 저장해야 함을 의미한다. 예를 들어, 메타(Meta)의 Llama-3 70B 모델을 FP16 정밀도로 추론한다고 가정해보자. 대략적인 하이퍼파라미터는 n_{\text{layers}}=80, n_{\text{heads}}=64, d_{\text{head}}=128이다.

이 경우, 시퀀스 길이 1 토큰당 필요한 KV 캐시 메모리는 다음과 같다:
2 \times 80 \times 64 \times 128 \times 2 \text{ bytes} \approx 2.62 \text{ MB}
이는 단 하나의 토큰, 단 하나의 시퀀스(Batch=1)에 대한 값이다. 만약 B=1인 상황에서 시퀀스 길이가 128,000(128k) 토큰에 도달한다면, KV 캐시의 총 용량은 다음과 같이 계산된다:
2.62 \text{ MB} \times 128,000 \approx 343 \text{ GB}
이 수치는 현재 상용화된 최고 사양의 AI 가속기인 NVIDIA H100 80GB 모델의 메모리 용량을 4배 이상 초과하는 크기이다.7 이는 단일 GPU에서는 128k 길이의 문맥을 처리하는 것이 물리적으로 불가능함을 의미하며, 여러 GPU에 캐시를 분산 저장해야 하는 복잡한 엔지니어링(Tensor Parallelism, Pipeline Parallelism 등)을 강제한다. 더욱이, 처리량(Throughput)을 높이기 위해 배치 크기 B를 늘리려 한다면, 필요한 메모리는 배치 크기에 비례하여 더욱 폭발적으로 증가한다.9

결국 트랜스포머 아키텍처 하에서 ’긴 문맥(Long Context)’을 지원한다는 것은, 곧 기하급수적인 메모리 자원을 투입해야 함을 의미하며, 이는 서비스 비용의 증가와 시스템의 복잡도 상승으로 직결된다.

2. 메모리 대역폭 장벽(Memory Bandwidth Wall)과 산술 강도

KV 캐시의 문제는 단순히 ’저장 공간(Capacity)’이 부족하다는 것에 그치지 않는다. 더 심각하고 근본적인 문제는 데이터를 메모리에서 연산 장치(Core)로 이동시키는 속도, 즉 **메모리 대역폭(Memory Bandwidth)**에 있다. 현대 컴퓨팅 아키텍처에서 연산 속도의 발전 속도는 메모리 전송 속도의 발전 속도를 압도하고 있으며, 이로 인해 발생하는 ‘메모리 장벽(Memory Wall)’ 현상은 LLM 추론, 특히 디코딩 단계에서 극명하게 드러난다.11

2.1 산술 강도(Arithmetic Intensity)와 루프라인(Roofline) 모델

이 현상을 이해하기 위해서는 **산술 강도(Arithmetic Intensity)**라는 개념을 도입해야 한다. 산술 강도는 프로세서가 메모리로부터 1바이트의 데이터를 가져왔을 때, 이를 이용해 수행하는 부동소수점 연산(FLOPs)의 횟수로 정의된다.13
\text{Arithmetic Intensity (OPS/Byte)} = \frac{\text{Total FLOPs}}{\text{Total Memory Access Bytes}}
**루프라인 모델(Roofline Model)**에 따르면, 모든 연산 작업은 컴퓨트 바운드(Compute-Bound) 영역과 메모리 바운드(Memory-Bound) 영역 중 하나에 속하게 된다.15

• 컴퓨트 바운드: 산술 강도가 높아, 데이터 전송 시간보다 연산 시간이 더 오래 걸리는 상태. GPU의 연산 성능(FLOPS)을 100% 활용할 수 있다.
• 메모리 바운드: 산술 강도가 낮아, 연산 장치가 데이터를 기다리며 유휴(Idle) 상태로 대기하는 시간이 더 긴 상태. 전체 성능은 메모리 대역폭에 의해 제한된다.

2.2 트랜스포머 디코딩의 산술 강도 분석

LLM 추론 과정은 크게 프리필(Prefill) 단계와 디코드(Decode) 단계로 나뉜다. 이 두 단계는 산술 강도 측면에서 극적인 대조를 이룬다.17

1. 프리필 단계: 입력된 프롬프트의 모든 토큰을 병렬로 처리한다. 이때의 연산은 주로 행렬-행렬 곱셈(GEMM) 형태를 띠며, 가중치 행렬을 한 번 로드하여 다수의 토큰 연산에 재사용하므로 산술 강도가 매우 높다. 따라서 프리필 단계는 주로 컴퓨트 바운드 영역에 속하며, H100과 같은 고성능 GPU의 연산 능력을 십분 활용한다.9
2. 디코드 단계: KV 캐시 문제가 발생하는 지점이다. 새로운 토큰을 하나 생성할 때마다, 이전에 저장된 거대한 KV 캐시 전체를 HBM(High Bandwidth Memory)에서 GPU 칩 내부의 SRAM(L1/L2 캐시)으로 로드해야 한다. 이때 수행되는 연산은 주로 행렬-벡터 곱셈(GEMV) 형태이다.

디코드 단계에서 어텐션 연산의 산술 강도를 분석해보자. 배치 크기 B, 시퀀스 길이 L, 히든 차원 D인 경우, 어텐션 연산에 필요한 데이터 로딩량은 KV 캐시 크기인 2BLD (FP16 기준 4BLD 바이트)에 비례한다. 반면, 수행되는 연산량(Key와 Query의 내적, Value와의 가중합) 역시 O(BLD) 수준이다. 구체적으로 살펴보면, 각 토큰 생성 시마다 4 \times B \times L \times D 번의 FLOPs가 발생하고, 메모리 접근량은 최소 4 \times B \times L \times D 바이트(파라미터 로딩 제외, 순수 KV 캐시 접근) 이상이다. 따라서 산술 강도는 대략 1 \sim O(1) FLOP/Byte 수준에 불과하다.20

최신 GPU인 NVIDIA H100 SXM의 경우, FP16 텐서 코어 연산 성능은 약 989 TFLOPS인 반면, 메모리 대역폭은 3.35 TB/s이다.7 이 하드웨어의 균형점(Machine Balance)을 계산해보면:
\frac{989 \times 10^{12} \text{ FLOPS}}{3.35 \times 10^{12} \text{ Bytes/s}} \approx 295 \text{ FLOPS/Byte}
즉, H100 GPU의 연산 성능을 온전히 활용하려면 데이터 1바이트당 최소 295번 이상의 연산을 수행해야 한다. 그러나 트랜스포머 디코딩 단계의 산술 강도는 1 내외에 불과하므로, 이는 극심한 메모리 대역폭 병목(Memory Bandwidth Bound) 상태임을 의미한다. GPU의 강력한 연산 코어들은 데이터가 HBM에서 도착하기만을 기다리며 대부분의 시간 동안 아무런 작업도 하지 못한 채 전력만 소모하게 된다.11

2.3 대역폭 병목이 초래하는 성능 저하

이러한 대역폭 제한은 실제 서비스 품질 지표인 지연 시간(Latency)과 처리량(Throughput)에 직접적인 악영향을 미친다.

1. 지연 시간(Latency)의 정체: 디코딩 속도가 연산 속도가 아닌 메모리 전송 속도에 의해 결정되므로, 아무리 연산 성능이 뛰어난 차세대 GPU가 출시되어도 메모리 대역폭이 획기적으로 늘어나지 않는 한 추론 속도는 빨라지지 않는다. 실제로 A100에서 H100으로 넘어갈 때 연산 성능은 3배 이상 증가했지만, 메모리 대역폭은 1.6배 증가에 그쳤다.23 이는 LLM 디코딩 성능 향상이 연산 성능 향상폭을 따라가지 못함을 시사한다.
2. 배치 처리의 비효율성: 일반적으로 GPU 활용도를 높이기 위해 배치 크기(Batch Size)를 키우는 전략을 사용한다. 배치 크기를 키우면 모델 파라미터(Weights)를 한 번 로드하여 여러 요청을 동시에 처리할 수 있어 파라미터에 대한 산술 강도는 높아진다. 그러나 KV 캐시는 각 요청마다 개별적으로 존재하므로, 배치 크기를 늘리면 로드해야 할 KV 캐시의 총량도 정비례하여 늘어난다.9 결국 배치 처리를 해도 KV 캐시 로딩에 의한 대역폭 병목은 해소되지 않으며, 오히려 VRAM 용량 부족으로 인해 최대 배치 크기가 제한되는 이중고를 겪게 된다.

3. O(N) 선형 증가의 덫: 하드웨어와 아키텍처의 불일치

트랜스포머의 어텐션 메커니즘이 갖는 O(N^2) 연산 복잡도에 대해서는 많은 논의가 있었으나, 추론 시점에서는 O(N)으로 증가하는 메모리 접근(Memory Access) 비용이 더 실질적인 위협으로 다가온다. 여기서 N은 문맥 길이(Context Length)를 의미한다. “선형적 증가“는 알고리즘 이론에서는 효율적인 것으로 간주될 수 있으나, N이 10만(100k), 100만(1M) 단위로 확장되는 초장문 문맥의 시대에는 이 또한 감당할 수 없는 비용이다.25

3.1 캐시 미스(Cache Miss)와 데이터 이동 비용

GPU의 메모리 계층 구조는 용량은 작지만 빠른 SRAM(L1/L2 캐시)과, 용량은 크지만 느린 HBM으로 구성된다. 이상적인 연산은 데이터가 SRAM 내에 상주하며 반복적으로 재사용되는 것이다. 그러나 트랜스포머의 디코딩 과정에서는 매 토큰 생성 시마다 과거의 모든 정보를 담은 KV 캐시를 HBM에서 SRAM으로 가져와야 한다. 캐시의 크기가 GB 단위로 커지면 SRAM 용량(수십 MB 수준)을 초과하게 되어, 매번 HBM 접근이 발생하는 ’캐시 미스’가 지속적으로 일어난다.

데이터 이동 에너지는 연산 에너지보다 훨씬 비싸다. 일반적으로 DRAM에서 데이터를 가져오는 데 드는 에너지는 부동소수점 연산을 수행하는 데 드는 에너지의 수백 배에 달한다. 따라서 KV 캐시의 크기가 커질수록 전력 소모가 급증하고, 시스템의 전체적인 에너지 효율성(Energy Efficiency)이 급격히 저하된다.12

3.2 현대 반도체 기술의 한계와의 충돌

이러한 현상은 ’무어의 법칙(Moore’s Law)’이 둔화되고 있는 현대 반도체 기술의 흐름과 맞물려 더욱 심각한 문제가 된다. 로직(Logic)의 집적도는 미세 공정의 발전으로 꾸준히 향상되고 있으나, 메모리 인터페이스의 대역폭은 패키징 기술과 물리적 배선의 한계로 인해 그 속도를 따라가지 못하고 있다. 트랜스포머 아키텍처는 태생적으로 메모리 대역폭을 과도하게 요구하는 구조를 가지고 있어, 이러한 하드웨어 발전의 불균형을 가장 아프게 찌르는 모델이다. 이는 단순히 더 좋은 칩을 만든다고 해결될 문제가 아니라, 아키텍처 차원에서의 재설계가 필요함을 강력하게 시사한다.26

4. 기존의 해결 시도와 그 한계점

물론 트랜스포머 진영에서도 이러한 KV 캐시 문제를 완화하기 위한 다양한 공학적 시도들이 있어왔다. 그러나 이들은 대부분 근본적인 해결책이라기보다는 증상을 완화하는 미봉책에 가깝다.

4.1 멀티 쿼리 어텐션(MQA)과 그룹 쿼리 어텐션(GQA)

가장 대표적인 접근은 KV 캐시의 크기 자체를 줄이는 것이다. **멀티 쿼리 어텐션(MQA)**은 모든 어텐션 헤드가 하나의 Key와 Value 헤드를 공유하도록 하여 KV 캐시의 크기를 1/n_{\text{heads}}로 줄인다.4 **그룹 쿼리 어텐션(GQA)**은 이를 절충하여 몇 개의 그룹으로 나누어 공유하게 한다. Llama-2와 Llama-3 등 최신 모델들은 대부분 GQA를 채택하고 있다. 이는 메모리 사용량을 줄여 배치 크기를 늘리고 대역폭 요구량을 낮추는 데 기여하지만, 정보의 표현력(Capacity)을 일부 희생하며, 여전히 시퀀스 길이에 비례하여 캐시가 증가한다는 O(N)의 근본적인 문제는 해결하지 못한다.27

4.2 PagedAttention과 메모리 관리 최적화

vLLM 등에서 도입된 PagedAttention은 운영체제의 페이징(Paging) 기법을 차용하여 KV 캐시를 비연속적인 메모리 블록에 할당함으로써 메모리 단편화(Fragmentation)를 줄였다.9 이는 주어진 메모리 공간을 더 알뜰하게 사용하여 배치 크기를 늘릴 수 있게 해주었으나, 물리적인 전송 데이터 양을 줄여주는 기술은 아니다. 즉, 대역폭 병목 현상 자체를 개선하지는 못한다.

4.3 양자화(Quantization)

KV 캐시 데이터를 FP16 대신 INT8, FP8, 심지어 4비트(NVFP4)로 압축하여 저장하는 양자화 기술도 적극적으로 도입되고 있다.28 이는 메모리 용량과 대역폭 요구량을 정밀도 비율만큼(예: 16비트 -> 4비트 시 4배) 줄여준다. 그러나 극단적인 압축은 모델의 정확도(Perplexity) 저하를 유발할 수 있으며, 특히 긴 문맥에서의 정보 손실이 우려된다. 또한, 이 역시 선형 증가의 기울기를 낮출 뿐, 증가 자체를 막지는 못한다.

4.4 추측성 디코딩(Speculative Decoding)

추측성 디코딩은 작고 빠른 드래프트 모델(Draft Model)을 이용해 여러 토큰을 미리 생성(Speculate)한 뒤, 큰 모델이 이를 검증(Verify)하는 방식이다.9 검증 단계에서는 여러 토큰을 한꺼번에 처리하므로 산술 강도가 높아져 대역폭 병목을 완화할 수 있다. 하지만 이는 확률적 방법에 의존하며, 모델 간의 정합성이 맞지 않을 경우 오히려 속도가 느려질 수 있다는 단점이 있다. 또한 KV 캐시의 절대적인 크기 문제는 여전히 존재한다.

5. 맘바(Mamba): 상태 공간 모델(SSM)을 통한 패러다임 전환

이러한 트랜스포머의 구조적 한계, 특히 ’기억을 유지하는 비용’의 무한한 증가라는 문제의식 속에서 맘바(Mamba) 아키텍처가 등장하였다. 맘바는 **상태 공간 모델(State Space Model, SSM)**에 기반을 두고 있으며, 트랜스포머와 달리 과거의 정보를 **고정된 크기의 상태(Fixed-size State)**로 압축하여 유지하는 방식을 취한다.30

5.1 고정된 상태 크기(Constant State Size)와 O(1) 추론

트랜스포머가 t 시점의 데이터를 처리하기 위해 1 \dots t-1까지의 모든 KV 캐시를 필요로 하는 반면, 맘바는 다음과 같은 순환적(Recurrent) 수식을 따른다:
h_t = A h_{t-1} + B x_t

y_t = C h_t

여기서 h_t는 시스템의 숨겨진 상태(Hidden State)를 의미한다. 중요한 점은 이 h_t의 크기가 시퀀스 길이 L과 무관하게 미리 정의된 상수 N (State Dimension)으로 고정되어 있다는 것이다.32 따라서 맘바는 문맥이 아무리 길어져도 추론 시 필요한 메모리 용량이 일정하며, 새로운 토큰을 생성하기 위해 이전 상태 h_{t-1}과 현재 입력 x_t 만을 연산하면 된다.

이는 추론 시 메모리 복잡도와 시간 복잡도가 모두 O(1)임을 의미한다. 트랜스포머가 과거의 모든 기록을 일일이 들춰보는 ‘데이터베이스 검색’ 방식이라면, 맘바는 핵심 정보를 요약하여 머릿속에 담아두는 ‘인간의 기억’ 방식과 유사하다.

5.2 메모리 대역폭 효율성의 극대화와 처리량 혁신

O(1)의 특성은 1.2.2절에서 논의한 메모리 대역폭 병목 문제를 원천적으로 해결한다. 맘바는 디코딩 단계에서 거대한 KV 캐시를 HBM에서 불러올 필요가 없다. 대신 작고 고정된 크기의 상태 벡터(State Vector)만을 갱신하면 되는데, 이 크기는 보통 수 킬로바이트(KB)에서 수 메가바이트(MB) 수준으로, GPU의 고속 SRAM(L2 Cache) 내에 충분히 상주할 수 있는 크기이다.34

이는 HBM 대역폭에 구애받지 않고 GPU의 연산 코어를 풀가동할 수 있음을 의미한다. 벤치마크 결과에 따르면, 시퀀스 길이가 길어질수록 맘바의 처리량(Throughput) 우위는 압도적으로 커진다. 트랜스포머가 시퀀스 길이에 따라 처리량이 급감하는 반면, 맘바는 128k, 심지어 100만 토큰(1M) 이상의 문맥에서도 거의 일정한 속도를 유지한다.36

5.3 선택적 상태 공간(Selective State Spaces)의 역할

물론 단순한 고정 상태 압축은 정보의 손실(Forgetting)을 야기할 수 있다. 기존의 RNN이 긴 문맥을 기억하지 못했던 이유가 바로 이것이다. 맘바는 이를 **선택적 메커니즘(Selection Mechanism)**을 통해 해결했다. 입력 내용에 따라 정보의 중요도를 판단하고, 상태(State)에 무엇을 남기고 무엇을 버릴지를 동적으로 결정하는 파라미터(B, C, \Delta)를 입력 x_t의 함수로 만듦으로써, 고정된 용량 안에서도 핵심적인 문맥 정보를 효율적으로 압축 저장할 수 있게 되었다.30

5.4 하드웨어 관점에서의 A100 vs H100 비교와 시사점

위 표에서 보듯, 최신 하드웨어일수록 연산 성능 대비 메모리 대역폭의 비율은 오히려 악화되고 있다. 트랜스포머는 이러한 하드웨어 발전 방향과 역행하는(대역폭을 더 많이 요구하는) 반면, 맘바는 연산 중심의 하드웨어 특성에 완벽하게 부합하는 아키텍처이다. 이는 맘바가 단순히 소프트웨어적인 혁신을 넘어, 미래 AI 하드웨어 생태계와의 정합성(Alignment) 측면에서도 탁월한 선택임을 시사한다.26

6. 하이브리드 아키텍처: 현실적인 타협과 미래

최근에는 맘바의 효율성과 트랜스포머의 고품질 생성 능력을 결합한 하이브리드(Hybrid) 아키텍처가 주목받고 있다. NVIDIA의 Nemotron-3, AI21 Labs의 Jamba 등이 그 예시이다.36 이들은 대부분의 레이어를 맘바(SSM)로 구성하여 KV 캐시 메모리 사용량을 최소화하고 처리량을 높이되, 일부 레이어에 어텐션(Attention)을 혼합(Interleave)하여 문맥 내 특정 정보의 정밀한 인출(Recall) 능력을 보완한다.

이러한 하이브리드 모델은 순수 트랜스포머 대비 KV 캐시 크기를 1/8 수준으로 줄이면서도 동등하거나 더 우수한 성능을 보여준다. 이는 ’KV 캐시의 저주’에서 벗어나기 위한 현실적이고 강력한 대안으로 자리 잡고 있다. 특히 1.2.1절에서 계산했던 수백 GB에 달하는 KV 캐시가 수십 GB 수준으로 줄어든다는 것은, 단일 GPU에서 처리 가능한 문맥의 길이가 수십 배 늘어난다는 것을 의미하며, 이는 비용 효율적인 AI 서비스 구축의 핵심 열쇠가 된다.

6.1 요약 및 결론

1.2절의 논의를 통해 우리는 트랜스포머 아키텍처가 가진 KV 캐시 문제가 단순한 메모리 용량 부족을 넘어, 메모리 대역폭의 물리적 한계와 직결된 구조적 결함임을 확인하였다. 시퀀스 길이에 비례하여 선형적으로 증가하는 메모리 요구량(O(N))은 긴 문맥 처리를 지향하는 현대 AI의 목표와 정면으로 충돌하며, 이는 아무리 빠른 반도체를 투입해도 해소되지 않는 ’메모리 장벽’을 형성한다.

이에 대한 해답으로 제시된 **맘바(Mamba)**는 ’기억’을 다루는 방식을 재정의함으로써(O(1) State), 메모리 대역폭의 제약에서 벗어나 연산 자원을 온전히 활용할 수 있는 길을 열었다. 이는 1.1절에서 다룬 O(N^2) 연산 복잡도 문제의 해결과 더불어, 1.3절에서 이어질 ‘긴 문맥 처리의 효율성’ 문제를 근본적으로 해결하는 토대가 된다. 포스트 트랜스포머 시대는 더 큰 모델을 만드는 것이 아니라, 더 효율적으로 기억하고 처리하는 아키텍처로의 진화를 의미하며, 맘바는 그 선두에 서 있다.

7. 참고 자료

1. KV Cache and KV Caching. The Hidden Bottleneck of LLM Inference | by Sulbha Jain, https://medium.com/@sulbha.jindal/kv-cache-and-kv-caching-a46acea80fe4
2. Understanding KV Cache: The Secret to Faster LLM Inference | by Sachin Soni | Nov, 2025, https://medium.com/@sachinsoni600517/understanding-kv-cache-the-secret-to-faster-llm-inference-a9a825d701de
3. KV cache strategies - Hugging Face, https://huggingface.co/docs/transformers/en/kv_cache
4. LLM Inference Series: 4. KV caching, a deeper look | by Pierre Lienhart | Medium, https://medium.com/@plienhar/llm-inference-series-4-kv-caching-a-deeper-look-4ba9a77746c8
5. KV Caching Explained: Optimizing Transformer Inference Efficiency - Hugging Face, https://huggingface.co/blog/not-lain/kv-caching
6. All the Transformer Math You Need to Know | How To Scale Your Model - GitHub Pages, https://jax-ml.github.io/scaling-book/transformers/
7. NVIDIA A100 vs H100 (2025): FP8/INT4, VRAM, NVLink & Price, https://www.bestgpusforai.com/gpu-comparison/a100-vs-h100
8. A Comparative Analysis of NVIDIA A100 Vs. H100 Vs. L40S Vs. H200 - Gcore, https://gcore.com/blog/nvidia-gpu-comparison
9. All About Transformer Inference | How To Scale Your Model - GitHub Pages, https://jax-ml.github.io/scaling-book/inference/
10. Transformer Inference Estimations: Arithmetic Intensity, Throughput and Cost Optimization, https://www.yadavsaurabh.com/transformer-inference-arithmetic-intensity-cost-and-optimization/
11. Mind the Memory Gap: Unveiling GPU Bottlenecks in Large-Batch LLM Inference - arXiv, https://arxiv.org/html/2503.08311v2
12. Transformers, https://aarnphm.xyz/thoughts/Transformers
13. [D] Understanding Optimal Batch Size Calculation - Arithmetic Intensity : r/MachineLearning, https://www.reddit.com/r/MachineLearning/comments/1lrc7vh/d_understanding_optimal_batch_size_calculation/
14. LLM Inference Series: 5. Dissecting model performance | by Pierre Lienhart | Medium, https://medium.com/@plienhar/llm-inference-series-5-dissecting-model-performance-6144aa93168f
15. AI: It’s All About Inference Now - ACM Queue, https://queue.acm.org/detail.cfm?id=3733701
16. LLM Inference Unveiled: Survey and Roofline Model Insights - arXiv, https://arxiv.org/html/2402.16363v4
17. Inside Real-Time LLM Inference: From Prefill to Decode, Explained | by Dev Patel | Medium, https://medium.com/@devsp0703/inside-real-time-llm-inference-from-prefill-to-decode-explained-72a1c9b1d85a
18. Probably an ignorant question, but could someone explain why the Context Length … - Hacker News, https://news.ycombinator.com/item?id=41585944
19. A guide to LLM inference and performance - Baseten, https://www.baseten.co/blog/llm-transformer-inference-guide/
20. Transformer Inference Arithmetic | kipply’s blog, https://kipp.ly/transformer-inference-arithmetic/
21. Trace - lecture_10 - CS336, https://stanford-cs336.github.io/spring2025-lectures/?trace=var/traces/lecture_10.json
22. What is the FLOPS Performance of the NVIDIA H100 GPU? | AI FAQ - Jarvis Labs, https://jarvislabs.ai/ai-faqs/what-is-the-flops-performance-of-the-nvidia-h100-gpu
23. [Discussion] Why is the fp16 TFLOPs of the H100 three times higher than that of the A100, but the training speed is only twice as fast? - Reddit, https://www.reddit.com/r/deeplearning/comments/1hbnp4e/discussion_why_is_the_fp16_tflops_of_the_h100/
24. NVIDIA Hopper Architecture In-Depth | NVIDIA Technical Blog, https://developer.nvidia.com/blog/nvidia-hopper-architecture-in-depth/
25. The Mamba Revolution: How State Space Models Are Challenging Transformers - Medium, https://medium.com/@aftab001x/the-mamba-revolution-how-state-space-models-are-challenging-transformers-4ad3b276b9a8
26. Mamba2: The Hardware-Algorithm Co-Design That Unified Attention and State Space Models | by Daniel Stallworth | Medium, https://medium.com/@danieljsmit/mamba2-the-hardware-algorithm-co-design-that-unified-attention-and-state-space-models-77856d2ac4f4
27. Hardware-Efficient Attention for Fast Decoding - arXiv, https://arxiv.org/html/2505.21487v1
28. Optimizing Inference for Long Context and Large Batch Sizes with NVFP4 KV Cache, https://developer.nvidia.com/blog/optimizing-inference-for-long-context-and-large-batch-sizes-with-nvfp4-kv-cache/
29. KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization, https://www.stat.berkeley.edu/~mmahoney/pubs/neurips-2024-kvquant.pdf
30. Mamba: Linear-Time Sequence Modeling with Selective State Spaces - arXiv, https://arxiv.org/pdf/2312.00752
31. Mamba Explained - The Gradient, https://thegradient.pub/mamba-explained/
32. How Mamba Beats Transformers at Long Sequences - Galileo AI, https://galileo.ai/blog/mamba-linear-scaling-transformers
33. Mamba for Dummies: Efficient Linear-Time LLMs Explained - Michiel Horstman - Medium, https://michielh.medium.com/mamba-for-dummies-linear-time-llms-explained-0d4b51efcf9f
34. State Space Duality (Mamba-2) Part I - The Model | Tri Dao, https://tridao.me/blog/2024/mamba2-part1-model/
35. Accelerating LLM Inference Throughput via Asynchronous KV Cache Prefetching - arXiv, https://arxiv.org/html/2504.06319v2
36. Inside NVIDIA Nemotron 3: Techniques, Tools, and Data That Make It Efficient and Accurate, https://developer.nvidia.com/blog/inside-nvidia-nemotron-3-techniques-tools-and-data-that-make-it-efficient-and-accurate/
37. [R] Mamba: Can We Achieve Infinite Context Length? : r/MachineLearning - Reddit, https://www.reddit.com/r/MachineLearning/comments/1it279f/r_mamba_can_we_achieve_infinite_context_length/
38. Mamba: Linear-Time Sequence Modeling with Selective State Spaces - OpenReview, https://openreview.net/forum?id=tEYskw1VY2
39. Nemotron-H: A Family of Accurate and Efficient Hybrid Mamba-Transformer Models - arXiv, https://arxiv.org/html/2504.03624v3